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COURTENAY, Administrative Patent Judge. 

DECISION ON APPEAL 

This is a decision on appeal under 35 U.S.C. § 134(a) (2002) from the 
Examiner's rejection of claims 1-35 and 37-64. Claim 36 is cancelled. We 
have jurisdiction under 35 U.S.C. § 6(b). 

We reverse. 
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Statement of the Case 
Invention 

The invention on appeal relates generally to network management 
systems. More particularly, Appellant's invention is directed to utilizing 
state-based polling to manage network elements. (Spec. 1). 

Illustrative Claim 

Claim 1 : A method for implementing a state model for managing a network 
coupled to a central management system, said method comprising: 

presenting a user interface for said central management system to 
enable a user to define at least one state model for managing said at least one 
network element based on a determined state of said at least one network 
element; 

presenting a user interface for said central management system to 
enable a user to define at least one poll service that includes at least one of 
said at least one state model; and 

executing said at least one poll service to manage said at least one 
network element. 

Prior Art 

The Examiner relies upon the following reference as evidence: 
Vaishnavi US 5,734,642 Mar. 31, 1998 

The Rejection 

The Examiner rejected claims 1-35 and 37-64 under 35 U.S.C. 
§ 102(b) as anticipated by Vaishnavi. 
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Issues 

Based upon our review of the administrative record, we have 
determined that the following issues are dispositive in this appeal: 

Issue 1: Under § 102, does Vaishnavi disclose or describe 
"presenting a user interface?" (Claim 1). 

Issue 2: Under § 102, does Vaishnavi disclose or describe "at least 
one state model capable of being dynamically defined during runtime?" 
(Claims 48 and 64). 

Issue 3: Under § 102, does Vaishnavi disclose or describe "receiving 
input from a user?" (Claim 35). 

Issue 4: Under § 102 does Vaishnavi disclose or describe a "user- 
defined state model?" (Claim 59). 

Principles of Law 
Anticipation under §102 
In rejecting claims under 35 U.S.C. § 102, "[a] single prior art 
reference that discloses, either expressly or inherently, each limitation of a 
claim invalidates that claim by anticipation." Perricone v. Medicis Pharm. 
Corp., 432 F.3d 1368, 1375 (Fed. Cir. 2005) (citing Minn. Mining & Mfg. 
Co. V. Johnson & Johnson Orthopaedics, Inc., 976 F.2d 1559, 1565 (Fed. 
Cir. 1992)). 
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Anticipation of a patent claim requires a finding that the claim 
at issue 'reads on' a prior art reference. In other words, if 
granting patent protection on the disputed claim would allow 
the patentee to exclude the public from practicing the prior art, 
then that claim is anticipated, regardless of whether it also 
covers subject matter not in the prior art. 

Atlas Powder Co. v. IRECO, Inc., 190 F.3d 1342, 1346 (Fed. Cir. 1999) 
(citations omitted). 

Findings of Fact 
In our analysis infra, we rely on the following findings of fact (FF) 
that are supported by the record: 

The Vaishnavi Reference 

1. Vaishnavi discloses a general purpose computer that includes a central 
processing unit (CPU) coupled to random access memory (RAM) and 
program memory via a data bus. The general purpose computer 
disclosed in Vaishnavi does not include a display monitor, keyboard, 
or mouse. (Col. 4, 11. 29-41; Fig. 7). 

2. Vaishnavi discloses that the polling manager provides poll requests to 
devices of the network to query the status of these devices. (Col. 5, 11. 
6-8). 

3. Vaishnavi discloses that status information sent to the network 
manager may include a "hardboot" message sent from a manageable 
device when the manageable device is initialized. (Col. 4, 11. 52-59). 

4. Vaishnavi discloses determining the previous state of a device by 
accessing a memory location that stores the status information, or 
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querying a model such as the object-oriented model of the device 
model described above. (Col. 6, 11. 27-31; Fig. 4). 

5. Vaishnavi discloses status information may include results from a 
discovery process. (Col. 5, 11. 24-25 and 44-56). 

6. Vaishnavi discloses a model control module coupled to a network 
model. (Col. 4, 11. 7-10; Fig. 2). The model control module creates 
and maintains device models that represent the status of manageable 
devices. (Col. 4, 11. 13-15). 

Analysis 
Issue 1 

We decide the question of whether Vaishnavi discloses or describes 
presenting a user interface. (Claim 1). 

Appellant contends that the general purpose computer illustrated in 
Fig. 7 of Vaishnavi does not include any user interface mechanism, and does 
not disclose any occasion in which a user interface mechanism would be 
required. (App. Br. 14). 

The Examiner contends that although Vaishnavi does not explicitly 
disclose a user interface, it is well-known in the art that a general-purpose 
computer has a user interface that allows a user to input information. (Ans. 
15). In the context of anticipation, we find the evidence before us supports 
the Appellant's position. 

In particular, we agree with Appellant that the general purpose 
computer disclosed in Vaishnavi does not include any means in which a user 
interfaces with the general purpose computer, nor do we find such a user 
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interface to be inherent in Vaishnavi. (FF 1). ^ Moreover, the Examiner's 
reliance upon a "well-known" element or feature (i.e., a user interface) is 
misplaced in the context of anticipation, which requires that each claim 
element be expressly or inherently taught by the reference. See Perricone 
432 F.3d at 1375. Based on the record before us, we find Vaishnavi does 
not disclose or describe a "user interface" as recited in independent claim 1. 
Accordingly, we reverse the Examiner's rejection under § 102 of 
independent claim 1 and associated dependent claims 2-34. 

Issue 2 

We decide the question of whether Vaishnavi discloses or describes 
"at least one state model capable of being dynamically defined during 
runtime." (Claims 48 and 64). 

Appellant contends that Vaishnavi does not disclose dynamic 
definition of a poll service during runtime by a user because Vaishnavi 
teaches that device model creation happens when the network manager is 
presented with a new device. (App. Br. 15, para. 3). 

In response, the Examiner contends that Vaishnavi discloses 
retrieving the previous state and status information before the model control 
is initiated. (Ans. 15) (emphasis added). 



^ Inherency . . . may not be established by probabilities or possibilities. The 
mere fact that a certain thing may result from a given set of circumstances is 
not sufficient." In re Robertson, 169 F.3d 743, 745, (Fed. Cir. 1999) 
(internal citations omitted). 
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We note that the express language of the claim requires that the 
executing state model be capable of being defined during runtime. {See 
claim 48). We find, as admitted by Examiner (Ans. 15), that Vaishnavi 
discloses at best that the definition occurs before runtime. 

Assumming arguendo that Vaishnavi' s status information is 
considered as defining a poll service, according to Vaishnavi the status 
information 17 is received by the network manager when the device is 
initialized. (FF 2-3). Further, Vaishnavi does not specify when other types 
of status information operations are performed, such as the discovery 
process and the response to a poll request. (FF 2 and 4-5). Therefore, we 
find that the Vaishnavi' s status information is not expressly nor inherently 
(necessarily) received by the network manager "during runtime" as required 
by the claim language. See Robertson, 169 F.3d at 745. 

Based on the record before us, we find that Vaishnavi does not farily 
disclose or describe "at least one state model capable of being dynamically 
defined during runtime," as recited in claims 48 and 64. Accordingly, we 
reverse the Examiner's rejection of independent claims 48 and 64, as well as 
the associated dependent claims 49-58. 
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Issue 3 

We consider the question as to whether Vaishnavi discloses or 
describes "receiving input from a user," as recited in independent claim 35. 

Similarly to the discussion supra regarding claim 1, Appellant 
contends that the general purpose computer disclosed in Vaishnavi does not 
disclose a keyboard, monitor, or mouse, and the system described in 
Vaishnavi is automated. (App. Br. 14). 

In response, the Examiner again contends that it is well-known that a 
general purpose computer has a user interface that enables a user to input 
information. (Ans. 15). 

We agree with Appellant's arguments for essentially the same reasons 
discussed supra regarding claim 1. The Examiner's reliance upon a well- 
known element or feature (i.e., a user interface to receive input) is misplaced 
in the context of anticipation, as discussed supra. Based on the record 
before us, we find that Vaishnavi does not disclose or describe "receiving 
input from a user," as recited in claim 35. Accordingly, we reverse the 
Examiner's rejection of independent claim 35, as well as associated 
dependent claims 37-47. 

Issue 4 

We decide the question as to whether Vaishnavi discloses or describes 
"a user-defined state model" as recited in independent claim 59. 

Appellant contends that user input is not needed in Vaishnavi because 
the system described therein is automated: a device status is determined, 
device data are collected, a new device status is determined, and an action is 
taken with respect to the device automatically. (App. Br. 14). 
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We are in agreement with Appellant's arguments. As stated above, 
we find that Vaishnavi does not disclose or describe any mechanism for user 
input. (FF 1). Further, we find that Vaishnavi does not state how the device 
models that represent the status of manageable devices are defined. (FF 5). 
Therefore, the Examiner has not established, and we do not find that a user 
or any other mechanism defines the device model as required by the claim 
language. Accordingly, we find that Vaishnavi does not disclose or describe 
"a user-defined state model" as recited in independent claim 59. 
Accordingly, we reverse the Examiner's rejection of independent claim 59 
and associated dependent claims 60-63. 

CONCLUSION 
Based on the findings of facts and analysis above: 
Vaishnavi does not disclose or describe "presenting a user interface." 
(Claim 1). 

Vaishnavi does not disclose or describe "at least one state model 
capable of being dynamically defined during runtime. "(Claims 48 and 64) 

Vaishnavi does not disclose or describe "receiving input from a user." 
(Claim 35). 

Vaishnavi does not disclose or describe "a user-defined state model." 
(Claim 59). 
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ORDER 

We reverse the Examiner's rejection of claims 1-35 and 37-64 under 
35 U.S.C. § 102(b). 

REVERSED 



Pgc 



HOLLAND & HART, LLP 
P.O BOX 8749 
DENVER CO 80201 



10 



